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The Formal Verification Used for the AAMP5 and AAMP-FV 
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It is becoming increasingly evident within the VLSI design industry that the complexity of many current 
hardware designs is outstripping the capability of traditional simulation-based tools to adequately verify 
them. This situation was well-illustrated by the recent floating point bug discovered in Intel’s Pentium pro- 
cessor. The industry is beginning to look at formal verification as a technological alternative to simulation 
for obtaining higher assurance than is currently possible. 




Recently, SRI International and Collins Commercial Avionics, a division of Rockwell International, un- 
dertook a project to explore how formal techniques for specification and verification could be introduced 
into an industrial process. The project, sponsored by the Systems Validation Branch of NASA Langley 
and Collins Commercial Avionics, consisted of specifying in the PVS language a portion of a Rockwell 
proprietary microprocessor, the AAMP5, at both the instruction set and register-transfer levels and using 
the PVS interactive proof-checker to show that the microcode correctly implemented the specified behavior 
for a representative subset of instructions. 


The main goal of the project was two-fold: First, to investigate the feasibility of formally specifying and 
verifying a complex commercial microprocessor that was not expressly designed for formal verification. 
Second, to explore effective ways to transfer the technology to an industrial setting. The choice of the 
AAMP5 satisfied the first goal since the AAMP5 was not designed for formal verification, but to provide 
a more than threefold performance improvement while remaining object-code-compatible with the earlier 
AAMP2, which is used in numerous avionics applications, including the Boeing 737, 747, 757, and 767. 

To satisfy the technology transfer objective, we had to develop a suitable verification methodology and a 
formal infrastructure to make the technology usable by practicing engineers. This infrastructure includes 
techniques for decomposing the microprocessor verification problem into a set of verification conditions 
that the engineers can formulate and strategies to automate the proof of the verification conditions. The 
development of the infrastructure was one of the key accomplishments of the project. Most of the in- 
frastructure and methodology are general enough to be reused for other microprocessors, certainly in the 
verification of another member of the AAMP family. This methodology was used to formally specify the 
entire microarchitecture and more than half of the instruction set and to verify a core set of eleven AAMP5 
instructions representative of several instruction classes. However, the methodology and the formal ma- 
chinery developed are adequate to cover most of the remaining AAMP5 instructions. Although PVS was 
the vehicle of the experiment, the methodology is applicable to other sufficiently powerful theorem provers. 

Another key result of the project was the discovery of both actual and seeded errors. Two actual mi crocode 
errors were discovered during development of the formal specification, illustrating the value of simply cre- 
ating a precise specification. Both were specific to the AAMP5 and were corrected before first fabrication. 
Two additional errors seeded by Collins in the microcode were systematically uncovered by SRI, who knew 
that bugs had been seeded, but not their location or identity, while doing correctness proofs. One of these 
was an actual error that had been discovered by Collins after first fabrication but left in the microcode 
provided to SRI. The other error was designed to be unlikely to be detected by walk-throughs, testing, or 
simulation. 


Steve Miller’s talk earlier in the workshop, gave an overview of the AAMP5 project emphasizing the tech- 
nology transfer process with its administrative and managerial aspects. This talk describes the technical 
approach used in verifying the AAMP5. Please refer to Steve Miller’s slides for the AAMP5 design figures. 
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The Formal Verification Technology Used for the A AMPS 
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normal_macro_machine.next_macro_state(st) = 

st WITH [(dmem) (word2denv(denv(st)) ) (tos(st)+i) 
(pc) := pc(st) + 1, 

(tos) :« tos(st) + 1] 


DPU Environment Assumptions 
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TVlax: AXIOM TVl(t+l) * IF DHLD(t) THEN TVl(t) ELSE TV(t) ENDIF • DLX pipeline [Burch & Dill: 1993] 

• UNITA [Windley: 1994] 



General Microprocessor Correctness 
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Abstraction function must be suitably "skewed” 

Length of instruction cycle can be idefinite not necessarily a 
function of the current visible state 
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Instruction-specific Verification Conditions 
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Is commercial processor verification technically feasible? 
Yes, if carefully planned and executed. 
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